Date: Sat, 9 Apr 94 04:30:25 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #105 

To: Ham-Digital 


Ham-Digital Digest Sat, 9 Apr 94 Volume 94 : Issue 105 


Today's Topics: 
Difference: 1270B and 1270C?? 
FCC Packet Message Forwarding 
Is KA9Q telnet correct? (virtual terminal) 
NTS---Hank Oredson notes 
RTTY for a beginner. 
sexually explicit talk 
TCP/IP <--> FBB ax.25 link 

TCP/IP from car w/PK-88 (Help) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Wed, 06 Apr 1994 12:56:32 +0600 

From: ihnp4.ucsd.edu! galaxy.ucr.edu!library.ucla.edu!agate!howland.reston.ans.net! 
math.ohio-state.edu!news.acns.nwu.edu! ftpbox!mothost!delphinium.cig.mot.com!mac- 
am-14.cig.mot.com!user@network. 

Subject: Difference: 1270B and 1270C?? 

To: ham-digital@ucsd.edu 


What is the difference between the MFJ 1270B and the "new" 1270C? 
Thanks, 


Marc Holdwick - N8KWX 


Date: 08 Apr 1994 16:03:22 GMT 

From: pa.dec.com!nntpd.lkg.dec.com!nntpd.bb.dec.com! waf@decwrl.dec.com 
Subject: FCC Packet Message Forwarding 

To: ham-digital@ucsd.edu 


But what constitutes "“atuhenticating" the source station? 


Bill Freeman, waf@zk3.dec.com, KE1G, PP-SMEL-IA(ME VFR only) N4365Z 
USABDA, MassABDA (novice modern), NMRA, rounds, squares, bad jokes. 
Telemarketing: Do more than just say no, write saying you seek other vendors. 


Date: Thu, 7 Apr 1994 20:34:23 +0000 

From: ihnp4.ucsd.edu!agate!howland.reston.ans.net! pipex!uknet! demon! 
llondel.demon.co.uk! dave@network.ucsd.edu 

Subject: Is KA9Q telnet correct? (virtual terminal) 

To: ham-digital@ucsd.edu 


Try looking at the ‘eol' command on KA9Q. I think there is some trickery 
involved to switch from the DOS newline to the Unix newline convention 
(similar to transferring ASCII files via ftp) which might even be done with 
some negotiation when opening the telnet connection. Possibly some flavours 
of software do it better than others? 


Dave 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


* G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on * 
* dave@llondel.demon.co.uk Internet x until the end. Then stop. * 
x g4wrw@g4wrw. ampr.org Amprnet x (the king to the white rabbit) x 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Date: Fri, 8 Apr 1994 14:10:34 GMT 

From: elroy.jpl.nasa.gov!swrinde! emory !wa4mei! ke4zv! gary@ames.arpa 
Subject: NTS---Hank Oredson notes 

To: ham-digital@ucsd.edu 


In article <22259.tao@maroon.tc.umn.edu> <tao@maroon.tc.umn.edu> writes: 
>Hank, an old time friend from the Twin Cities now in "exile" in Oregon 
>said about the BBS/NTS interface: 

>> 

>>'But in any case, stop trying to force fit things that were appropriate 
>>40 or more years ago to the present reality. ' 


>oA.6 

>> 

>> ... Hank 

> 

>Of course Hank is right about this. The "regular" NTS, something Hank and I 
>and many others participated in years ago, was and is a training ground to 
>learn message handling in a format useful in emergencies and for military 
>use. 

> 

>The problem is, the telephone is so ubiquitous and so low cost, that 
>handling messages that may or may not get delivered rates right up there 
>with exchanging re-tries on HF packet. (STA or otherwise) . 

[snip] 

>Forty years ago the communications world was different and the choices 
>available and the choices made were different too! Our current culture 
>really does not lend itself to the classic NTS format and activity and, as 
>a result, we probably can expect it to gradually fade away. 

> 

>If you have thoughts on where we may be evolving to I would very much like 
>to hear them. 


As much as I would like to see amateur radio continue to provide useful 
message handling systems for emergencies, Mr. Olson is right, our methods 
and modes are obsolete in the modern world, except in very rare and limited 
cases. If we are to be of help in this arena, and I think we still can be, 
then we have to rethink our approach. 


For those of us interested in digital modes, the challenge is to seamlessly 
internetwork with the "information superhighway". The NTS message format 

is not compatable with that goal because it was intended to be handled 

with human interpretation and human intervention. We need to re-examine 

the way we handle messages, and the format in which they are cast. 


Key areas we need to examine are format, addressing, routing, and assured 
delivery. RFC822 or X400 messaging standards give us frameworks for messages 
that can transparently move over many disjoint networks. The ticklish problems 
we face are in resolving a message addressee to a machine address, and in 
dynamically building routing systems that can deal with our often transient 
systems and links. (We should be able to act as bridges across broken 
commercial links in time of emergency without having to handle messages 

by hand, and we should be able to utilize commerical networks for part 

of our delivery system, again without need of by hand manipulation.) 


Because of the disjoint nature of our networks, and because realtime 
connectivity across the networks is a rare thing, we can't depend on a 

level 4 transport protocol like TCP to meet our end to end message handling 
needs, though it's useful in assuring delivery across intermediate connected 
segments of the networks. Nor can we use IP to route our messages because 


there's no dynamic route building mechanism in current implementations that 
can handle transient connectivity and the dynamic message addressee to 
destination machine address mapping we require, though we can use IP across 
connected segments of the networks while forwarding our messages. 


But messages of the types we're considering are at a higher level of 
abstraction than is addressed by TCP/IP. That's where the BBS and it's 

Sysop have tried to fill the gap. Instead of sending and receiving packets, 
the BBS sends and receives whole messages. Instead of resolving packet 
addresses and developing dynamic packet routes, the BBS must resolve 

message destination address mappings, and develop dynamic message delivery 
routes. (SMTP is a method that does this, but it can't cope with the disjoint 
nature of our amateur networks.) 


It's the same idea as what TCP/IP does on the packet level in semi-realtime, 
so we can apply many of the concepts developed for TCP/IP in our message 
handling systems. But there are significant differences too. Mainly because 
we can't expect timely end to end response, we have to alter the way we 

do name service resolution of addresses, and because of the disjoint store 
and forward nature of the network segments, we have to change the way 

we guarantee end to end integrity and delivery. 


The one thing we can't do is allow copies of messages to be diverted 

to alternate delivery systems in mid-stream. Daniel gave us a way to 

kill duplicates at a destination machine, so having duplicates circulating 
inside our networks isn't a serious concern. For example we could try a 
flood algorithm in order to insure rapid delivery of a priority message 

to a destination machine. Daniel's mechanism of message hashes would 

kill later arriving duplicates. But if we allow the messages to be 

visible at intermediate machines, they can be diverted to alternate 
delivery mechanisms, such as voice, RTTY, or CW NTS nets. And subsequently 
delivered, or reinserted into the packet system in a form that defeats 
hash checking, or with altered routing to a different destination machine, 
so that they are taken and delivered again. 


So my first concrete suggestion to the BBS authors is to make NTS 
messages invisible to potential NTS traffic takers on intermediate 
machines. My second concrete suggestion is that NTS messages on 
destination machines should auto-kill when the user who downloads it 
logs off the system, and an automatic service message be generated back 
to the originating BBS listing the call of the user taking the traffic. 
NTS users must be educated that if they download a piece of NTS traffic, 
they have then accepted responsibility for delivering that traffic. 
(Note, it would be nice if there were an "oops" command so that a 
mistakenly downloaded message could be re-enabled on the BBS if the 
user decides before logging off that he can't handle it after all.) 


>Tod Olson, KOTO 


>ARRL Director, Dakota Division 


Unrelated note: It's very refreshing to see a Director actively 
participating here. Welcome! 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


Date: Thu, 7 Apr 94 18:57:00 -0800 

From: ihnp4.ucsd.edu!usc!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nntp- 
server.caltech.edu!news.claremont.edu!kaiwan.com! ledge! bob.albert@network.ucsd.edu 
Subject: RTTY for a beginner. 

To: ham-digital@ucsd.edu 


Yes, RTTY is usually FSK or AFSK. The common frequency shifts are 
170 Hz (current) and 850 Hz (somewhat obsolete). It uses a 5 bit 
Baudot code, the details of which are in most ARRL handbooks. Asa 
matter of fact, you would do well to pick up a copy and see what's 
in there on the subject; at least the older books had a good 
description. 73 DE K6DDX 


Date: 8 Apr 1994 11:19:35 +0100 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!uknet! acorn! not-for- 
mail@network.ucsd.edu 

Subject: sexually explicit talk 

To: ham-digital@ucsd.edu 


In article <765776764snx@skyld.grendel.com> jangus@skyld.grendel.com (Jeffrey D. 
Angus) writes: 

>In article <Cns42x.2Bu@iat.holonet.net> bgould@iat.holonet.net writes: 

> > I don't have a liscense, but I bought a ham radio recently and was thining 
> > about opening sexually explicit gay chatline through info packets over the 


etc 


It seems such a shame to leave out the people from the two remaining 
flamethreads, so how about encrypting the traffic and sending it CW ? 


-adrian 


Date: Fri, 8 Apr 1994 12:54:24 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!howland.reston.ans.net!math.ohio- 
state.edu! jussieu.fr!univ-lyon1.fr!swidir.switch.ch!news.unige.ch!ugun2a! 
pfund@network.ucsd.edu 

Subject: TCP/IP <--> FBB ax.25 link 

To: ham-digital@ucsd.edu 


In article <OLHAOY3WODEAP1KTAW@rivendell.otago.ac.nz>, 
HOSPICE@rivendell.otago.ac.NZ writes: 

> Re: Subject: TCP/IP-f£6f£bb (ax25) link, how do you do it ? 

> 

> Daniel writes: 

> 

>>Would anybody know how to manage forward between a tcp/ip STATION 

>>and a f6fbb BBS without being declared as a BBS (eg, when you send out 
>>to the £6fbb BBS the command sp xxxxx < hb9vbc @ hb9vbc, it immediately 
>>advises the sysop and tells you that they don't forward to hb9vbc bbs!) 
>>Where does this have to be fixed ? 


> 

> Sending SP ZL4ABC < ZL4DEF @ ZL4GHI to an FBB BBS results in an msg labelled 
> like this: 

> 

> Message Choice - [x] 

> Msg # TSL Size To @BBS From Date/Time Subject 

> eeeeee ew @® = ew B® ee wee ewww ew w@ ewww eg ew ew ew ew ew ew Pw ew ew ew ew ew ew eB ew eB el BM Bw ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ee 

> 25493 PNL @ ZL4ABC@ZL4GHI ZL4DEF 940401/00:58 TEST 

> 

> As you have discovered, unless the FBB has a forwarding path set for the 

> @BBS, then it goes nowhere and the sysop gets a msg. 

> 

> Posting the same SP on a JNOS station produces a msg for ZL4ABC on that 

> JNOS station, with the msg being labelled as coming from ZL4DEF@ZL4GHI. 

> 

> If you could state your intent in posting that address format to an FBB, more 
> useful help may be possible. 


> 

Yes, I would exactly like to do that, automatically from NOS. Send the 
fbb bbs a message with the from BBS that has the same address as that fbb 
BBS. Example: I'm a NOS user, so I would be declared hb9vbc @ hb9vbc.ampr.org 
I also use an AX25 BBS called hb9iap.srom.che.eu, so I would like to smtp 

the ax25 bbs and tell NOS to use instead of the form sp xxx < hb9vbc @ hb9vbc 
the form : sp xxx < hb9vbc @ hb9iap. Is this possible ??? 


/// Daniel Pfund Internet: pfund@uni2a.unige.ch 
__/// University of Geneva, Economics AX25: hb9vbc@hb9iap.srom.che.eu 
\\\/ only AMIGA makes it possible ! ham radio amateur 


Date: Fri, 8 Apr 1994 12:46:09 GMT 

From: ihnp4.ucsd.edu! library.ucla.edu!csulb.edu!csus.edu!netcom.com! 
henrys@network.ucsd.edu 

Subject: TCP/IP from car w/PK-88 (Help) 

To: ham-digital@ucsd.edu 


Andrew J. Doane (adoane@interaccess.com) wrote: 

: I have just recently purchased a laptop, and since I have a PK-88 here 
: I have not used for a year or so, already have a 50w VHF radio in the car 
: that doesn't get much use (I'm a UHF nut), and I already have a TCP/IP 
: address allocated to me, I would like to use TCP/IP from the car. 
Andrew, 

(This has nothing to do with TCP/IP.) 

I thought that I was nuts for running CW from the car :-) 

And now back to your normal thread. 

Good luck, 

Smitty, NA5K/m 


Henry B. Smith - NA5K henrys@netcom.com 
Dallas, Texas 


"I'm not sure I understand everything that I know" 


Date: Thu, 7 Apr 1994 20:31:19 +0000 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!uknet!demon! 
llondel.demon.co.uk! dave@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <5155Jc1w165w@aznet.stat.com>, <765383670snz@topsy.demon.co.uk>, 


<2nupb4$1mp@gopher.cs.uofs.edu>uk 
Subject : Re: TNET-X1J 


In article <2nupb4$1mp@gopher.cs.uofs.edu> bill@triangle.cs.uofs.edu (Bill 
Gunshannon) writes: 

>There was talk a while back about someone working on a version of TNET-X1? 
>that would work in the DR-200. Has this ever been done?? 

> 

That was me.... I have the source, I even have a DR200 but trying to get hold 
of a Z80 C compiler which will do the necessary tricks for overlays etc to get 
the code to fit is not proving quite so easy. I daresay if I spent enough 
money I could get a commercial offering capable of doing it but it would be 

a lot of money for a one-off project. I did try the public-domain Hitech C 
(running under a CP/M emulator on my PC) but that won't do the necessary 
tricks. I haven't found a decent Z80 cross-compiler for the PC yet so I am 
open to suggestions. 


Dave 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKK 


* G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on * 
* dave@llondel.demon.co.uk Internet x until the end. Then stop. * 
x g4wrw@g4wrw. ampr.org Amprnet * (the king to the white rabbit) x 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Date: 7 Apr 1994 17:19:10 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!sunic!psinntp!psinntp! 
news .mentorg.com! hpbab33.mentorg.com!wv.mentorg.com!hanko@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <CnssC5.6pq@world.std.com>, 
<1994Apr5.222105.9528@newsgate.sps.mot.com>, <CnunkKr.6D3@world.std.com>ko 
Reply-To : Hank_Oredson@mentorg.com 

Subject : Re: NTS traffic on packet 


In article <Cnunkr.6D3@world.std.com>, dts@world.std.com (Daniel T Senie) writes: 
|> In article <1994Apr5.222105.9528@newsgate.sps.mot.com> 
kinzer@dtsdevO.sps.mot.com (Dave Kinzer) writes: 

|> >In article <CnssC5.6pq@world.std.com> dts@world.std.com (Daniel T Senie) 
writes: 


|> Actually, the need for rescuing is a BIG problem, and indicates a failure 
|> in the network. At least SOME of the BBS systems show the NTS traffic as 
|> listable on EVERY node it passes through, for the duration of the stay 
|> at that node. If this were not the case, and a link between nodes were 


|> down (or the BBS at the other end of the link is down) then the NTS message 

|> would be delayed, and not be visible to any user, until the link or distant BBS 
|> returned. This would result in a delayed NTS message, with NO confirmation 

|> or information to the originator that the message is not getting through. 


Sounds to me like some NTS folks need to talk to the BBS sysops involved, 
and give them some guidelines on how NTS would like it's traffic handled 

within the BBS network. I would expect NTS to contact me (as well as the 
other BBS authors) about these issues; they have not done so. 


|> The skepticism on the part of many NTS operators comes from the need to 
|> trust a distributed system of unknown (at the moment of sending) reliability 
|> to get the message through. 


Have there been major problems? Does the NTS liason who takes the message 
and delivers it notify the NYS liason who put it into the BBS network? If 
they do, what sorts of problems are seen? 


At least in this area of the country, I hear a lot of whining from the NTS 
folks, but when I look at my own BBS system I see xallx NTS traffic 
clearing within 24 hours - to any part of the US and CANADA. The only 
traffic that remains "stuck" is traffic destined to my local area. 
Sometimes no NTS liason checks the BBS for several days. 


|> I use packet nearly every day to communicate with folks, but often will 
|> ask when on a voice mode if they got the message or not. 
|> 


Why not ask on packet? 
The SR command is not really all that hard to type. 


|> As noted above, it is not "temptation" that causes trouble. If an intermediate 
|> BBS allows a user to list the traffic, and to KILL the traffic, then that 

|> user has assumed responsibility for the message. It does not matter if the 

|> message gets to the "right" BBS near the destination zip code, just so long 

|> as SOMEONE is able to pick it up, and kill it, and have that ONLY HAPPEN 

|> ONCE! 


And if there is any doubt about who took the traffic from the BBS system, 
the BBS log files can confirm who took it, when they took it, etc. 


If NTS wants confirmation of the point of exit from the BBS system, a 
Simple SR and message with "I took your number xxx" is all that is 


required. 


Hank 


Hank Oredson @ Mentor Graphics 
Internet : hank_oredson@mentorg.com 
Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


End of Ham-Digital Digest V94 #105 
KKKKKKKKKKKKKKKKKKKKKEKKEKRKA KAKA 


